Columbia Kermit/kermit.zip/newsgroups/misc.20000114-20000217/[e-mail] _Wed Jan 19 00:26:15 2000.msg

Internet Message Format | 2020-01-01 | 15KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id AAA04930
    for <[e-mail]>; Wed, 19 Jan 2000 00:26:14 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id AAA21926
    for [e-mail]; Wed, 19 Jan 2000 00:04:54 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: [e-mail] (Jeffrey Altman)
Subject: Re: MS-DOS Kermit, more capabalities
Date: 19 Jan 2000 05:04:53 GMT
Organization: Columbia University
Message-ID: <863gll$ld3$[e-mail]>
To: [e-mail]

In article <VU7h4.9208$[e-mail]>,
 <[e-mail]> wrote:
[discussion of Michael as a wonderful person and macro programming
 genius deleted]

Michael may be a fantastic macro programmer.  But I do not have
the time to be a consultant to everyone that chooses to send me
several hundred lines of Kermit script.


[discussion of broken mail programs deleted]

If the mail programs are broken then it would make the most sense
to put the energy into fixing them.  Not trying to twist MS-DOS Kermit
into something it was not designed to be; even if it can be made to do
it.

:
:     I  would  be  curious  to  see  that.  I  use public access LYNX
:     (because  it  includes  a very good implementation of the kermit
:     transfer) to browse websites when using MSK.

The Kermit implementation that Lynx uses is C-Kermit.  It does not
have its own independent kermit implementation.  It simply takes
advantage of the work that has already been put into C-Kermit in
much the same way that we advise BBS operators to take advantage of
the work that has been put into MS-DOS Kermit.

:     It is the same for Michel, a form of entertainment.

: JD> I  have  no plans of touching zmodem file transfer material.
: JD> It  is a different universe to construct and that would both
: JD> bloat  MSK  and  make life confusing to users because of the
: JD> much different command sets.
:
:     Millions do manage both. 8)

What does this fact have to do with the situation at hand?
Professor Doupnik is the one that has to support the end users of
MS-DOS Kermit.  He does not want to have to suupport the users that
will become confused.  That is his choice.

[a lot of other extraneous arguments deleted]

:     What  is  _needed_ is no more nor less than K95 user _need_. K95
:     needs  zmodem  and kermit, MSK needs the same. People are people
:     even if they aren't cororate managers with cute titles.

I am going to try to explain the history of Kermit 95 in some greater
detail with the hope that people will stop trying to compare MS-DOS
Kermit and Kermit 95.

Kermit 95 is a commercial product which was not derived from stolen
code (as has been implied by Michael.)  K95 is the successor to
the OS/2 version of C-Kermit 5A(191) which was the work of myself
and Kai Uwe Rommel.  At the time C-Kermit for OS/2 was introduced
it did not have a Zmodem library.  Nor did I have any interest in
writing one.

It is interesting to remember that at the time people were jealous of
the fact that people could take MS-DOS Kermit and be able to perform
Zmodem transfers using DSZ.  Jyrki Salmi was a student working part
time on an OS/2 BBS for which he was recommending K2 as the client.
Since Omen Technologies did not have a Zmodem implementation for
OS/2 and wanted a large sum of money to license the source code, Jyrki
wrote his own Zmodem library which he called P.  P was designed like
DSZ to be run as a subprocess and be passed the file handle for the
communications device.  This worked fine when most people were using
Kermit to dial the calls, but it did no good when they wanted Zmodem
for other types of connections (LAT, TCP/IP, NetBIOS) that K2 supported.

There was something very important to note about P.  P was released as
two parts: a DLL which implemented the Zmodem protocol and an EXE
front end which handled the i/o.  While the source code to the EXE was
released to the world with Jyrki's copyright he never released the
source code to the DLL.  This was following the same policy that I had
for the K2 source code.  I released binaries to the world but never
released the source code.  Why?  Because in all the years that I was
working on porting Kermit to 32-bit OS/2, developing terminal
emulations, and implementing communications methods, no one (other
than Kai Uwe Rommel) ever offered to lend a hand.

When I was hired by the Kermit Project to develop a version of Kermit
for the forthcoming Windows 95 operating system Jyrki and I made a deal.
The result of the agreement was that the Kermit Project would receive
the source code and a license to port it to Win32, but we did not have
a license to release the source code to the public.  The copyright
would remain with him (or whoever he chose to sell it to.)

When I said that I put Zmodem into Kermit 95 I meant it.  Not only did
I port P to Win32, but I integrated the P API into K95 so that its i/o
mechanisms would be used instead of those designed by Jyrki.  When
Professor Doupnik says that adding Zmodem to Telnet and integrating it
with the Kermit notions of file collisions, window sizes, resend
capabilities, file logging, control character prefixing, ... is not a
trivial matter, he is not kidding.  How do I know?  Because I've
already done it once and I had the benefit of using one of the cleanest
Zmodem APIs I have ever seen.  Jyrki did a fantastic job.

At first I thought that all I would do is enable the protocol to be
switched to Zmodem instead of Kermit, and then when a file transfer
took place I could just funnel things through the P DLL.  Sounds easy
but we quickly ran into problems.

Not all telnet servers use a Telnet connection as an NVT.  Some use
Binary mode in one direction or both.  It is necessary for the file
transfer engine to know about these modes and be able to toggle quoting
on the fly.  The i/o needs to be able to bypass the file transfer
midstream to handle incoming telnet option negotiations.  And to make
matters worse, unlike the Unix and VMS worlds, the BBS implementors
apparently did as bad a job of reading the Telnet RFCs as they did
reading the Kermit protocol specifications.  In many cases they made
significant mistakes.  One prominent one is the negotiation of telnet
binary mode in one direction or the other, but using it in both.  We
were forced to implement workarounds for this because unlike Kermit
protocol Zmodem did not provide for selective quoting of control
characters because it was designed for 8-bit clean connections.

When P was an external add-on for K2 users understood that they would
not get file transfer logging, attribute preservation, file transfer
selectivity, the ability to script transfers, etc.  However, once
P was integrated into K95 that changed.  Now users wanted every feature
that Kermit protocol had to be supported for Zmodem.  Performing
this integration took over a year.  The result of which allowed us
to support external Zmodem processes as inline file transfer methods
not only in Kermit 95 but in C-Kermit as well.

The points to take from this are as follows:

. The integration of Zmodem into Kermit when the API has already
  been written and the language is C, not assembler, is a non-trivial
  undertaking if you are going to do it correctly.

. Performing Zmodem file transfers as an external add-on over a raw
  TCP/IP connection is possible; over Telnet it requires that there
  been a tight couplling between the Zmodem engine and the Telnet
  engine such that using an external process to handle the Zmodem
  will not work reliably in the very environment which you wish to
  use it.

. The Zmodem library which is built into Kermit 95 was not developed
  by the Kermit Project, and its use is governed by the copyright
  holder.  Even if we were at liberty to integrate it into MS-DOS
  Kermit, and Professor Doupnik had the time and desire to do so,
  we would not be able to distribute the source code.  MS-DOS Kermit
  is distributed as a binary for the convenience of those without
  the necessary development tools, but its primary means of distribution
  is in source form.  The P library could not be distributed as a
  part of MS-DOS Kermit.

. I, as the sole author of Kermit 95, have the privilege of deciding what
  features go into it just as Professor Doupnik has the privilege
  of deciding what work will be done to MS-DOS Kermit.  When some
  one comes asks us to implement a feature we evaluate the feature
  and determine

    (a) if we personally need the feature;

    (b) how much fun it would be to implement;

    (c) how much time it would take;

    (d) how much support we will need to provide for it after it
        is implemented; and

    (e) whether it would break backwards compatibility

  Then we decide whether it is something we want to do.

The Zmodem question has been asked so many times over the last 15
years that somebody who just walks into this forum and says "Why
don't you implement Zmodem" might interpret the negative response
as a knee jerk response.  It isn't.  We have 20 years of experience
developing and supporting communications packages that implement
the Kermit protocol.  Unlike most other open source products, Kermit
has had not just community based support but also a dedicated
group made up of the authors of the software, as well as paid
telephone helpdesk support.  When users can't get something to
work with their communications software they usually do not have
the option of sending an e-mail.  Instead they pick up the phone.
For the last twenty years we have been there to develop the software
and answer the phone.  To get some idea of what most of our users
think of the support we provide please review

  http://www.columbia.edu/kermit/tsreviews.html

The point that I have tried to make in previous postings about
somebody other than Professor Doupnik developing the Zmodem
implementation and donating it back to the Kermit community
is to address item (c).  If someone comes to us and says "kermit
is a great program.  I've used it to do so many things but it
just couldn't do this one thing, so I implemented it.  Could you
add it to the next release?"  We are going to have a very different
reaction than somebody who we have never heard of before telling
us what we should do, how easy it would be to do, and why we
are jerks for saying "sorry, but no."

:     It's  really  too bad you didn't use this "transport layer blob"
:     phraseology  with the author of WATTCP long ago. I'm certain the
:     outcome  of your joint venture would have been different than it
:     has  been  and  we  wouldn't be having this conversation at all.
:     Have a nice day.

The separation of the WATTCP and MS-DOS Kermit code is ancient
history.  It is improper to look at the decisions that were made in
1991 given the changes that have occurred in the last nine years.

This is beginning to remind me of the recent arguments that have taken
place in the open source crypto community over how Netscape sold their
soul to the devil when they chose RSA's patented public key
certificates over the currently unpatented D-H based DSA algorithems.
At the time the decisions were made very few people had experience
with DSA and both RSA and D-H algorithms were patented.  The fact that
the D-H patent was expiring approximately two years before RSA was not
a significant concern compared to the trust people had in RSA and the
lower computational requirements that RSA imposed.

The reality is that given the circumstances at the time, decisions
were made.  To try to make the case that things woulld be different
if only some person had known better is a waste of time.

Jeffrey Altman
Senior Software Designer
The Kermit Project

P.S.  The reason that I refer to Professor Joe Doupnik as Professor
Doupnik in my postings is as a sign of respect.  Professor Doupnik
was developing MS-DOS Kermit when I first entered college.  I used
MS-DOS Kermit throughout my college years as it was distributed to
just about everybody at a college campus in the United States that
needed remote dialup (and then later network) access.

I've never met Professor Doupnik and when we first started conversing
about MS-DOS Kermit in the late 80s I was still an undergrad.  So
my relationship with him was as a Professor to a student.  Even if he
wasn't a faculty member at the University I attended.

My exposure to Kermit was as a user of MS-DOS Kermit so I could work
from my dorm room late at night instead of from the labs.  I then
became a beta tester and a contributor of automated install scripts.

When 32-bit OS/2 was released I founded the first U.S. OS/2 user's
group and promptly started to work on a version of Kermit for that
platform.  Kai Uwe Rommel had already implemented a version for 16-bit
OS/2 but did not have the time to work on a full 32-bit port nor
to flesh out the terminal emulator, integrate it with the OS/2
Workplace Shell, the clipboard, add mouse support, etc.  So I took
over responsibility.

P.P.S. Kermit 95 and a lot of C-Kermit 7.0 are the result of my hard
work.  Someone asked how much code there is: Unix C-Kermit is
approxmately 225,000 lines of C.  Kermit 95 has an additional 125,000
lines not including any of the external utilities that we ship such as
the K95 Dialer front end.  In addition to this are 44,000 lines of
documentation which are supplements to the 700 page "Using C-Kermit"
book.

P.P.P.S. As for Michael's comments that I should be a politician
because of my work on Standards bodies, I will take that as a compliment.
The Internet is an engineering nightmare that is built on standards.
The fact that you can make a TCP/IP from New York to Stockholm,
negotiate a terminal type, authenticate your self to the host and vice
versa, privatize the data stream with a negotiated encryption algorithm
and a secret key, and then transfer a file across the session is not
entirely an accident.  It is possible because 2000 engineers volunteer
their time to meet three times a year, debate the merits of submitted
protocols, and prove their cases with implementations.  A large part
of this process is political because that is how a democratic group
negotiates an agreement that everyone can live with.








    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [e-mail]